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REMARKS 

Applicant appreciates the time taken by the Examiner to review Applicant's present 
application. This application has been carefully reviewed in light of the Official Action mailed 
April 22, 2004. Applicant respectfully requests reconsideration and favorable action in this 
case. 

Rejections under 35 U.S.C. S 102 
Claims 1, 2, 4, 7-8, 10-13, 15-16, 19-23, 28-30, 34 and 37-38 stand rejected as 
anticipated by U.S. Patent No. U.S. Patent No. 6,400,730 ("Latif ). 

Claims 1,10 and 23 have been amended to recite that a request from the first device is 
a "non-SCSI formatted request." The request sent according to the second protocol, however, 
can be reformatted according to the SCSI protocol or a protocol, such as fiber channel, that 
encapsulates SCSI. Latif, on the other hand, neither teaches nor suggests that the switch 
should reformat non-SCSI formatted commands. Instead, the portions of Latif cited by the 
Examiner essentially teach a system of re-encapsulation of SCSI formatted commands. More 
particularly, in Latif, SCSI formatted commands can be received over an IP connection (SCSI 
over IP or "SolP"), a SCSI interface or a fiber channel interface. Using the example of IP to 
Fiber Channel in Latif, the SCSI commands from a SolP device are encapsulated in fiber 
channel data and the fiber channel data encapsulated in IP packets for transmission to the 
switch. The switch of Latif extracts the fiber channel frames from the IP packets and sends the 
fiber channel data to the fiber channel device. See col. 7, lines 3-8. In the reverse direction, the 
switch can receive fiber channel data from the fiber channel device, encapsulate the data in an 
Ethernet packet and sent the Ethernet packet to the SolP device according to the IP protocol. 
See col. 8, line 15-63. Because the switch of Latif simply re-encapsulates SCSI commands 
according to various protocols, there is no motivation to translate non-SCSI commands from a 
first protocol to a request according to a second protocol. If the Examiner disagrees, applicant 
respectfully requests that the Examiner point out where the received request that is not 
formatted according to a SCSI protocol is found in the cited reference or allow Claims 1,10, 23. 

With respect to Claims 30 and 34, Claim 30 of the present invention recites identifying a 
keyword in a first request, wherein the keyword indicates the format of the information in the 
first request" and "parsing the first request based on the keyword" and Claim 34 recites that the 
first device is configured to "generate a first request containing a keyword indicating an 
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arrangement of information in the first request" and that the switch is configured to parse the 
first request based on the keyword. In the present invention, as recited in Claim 30 and 34, the 
first request can include a keyword that indicates how information in the request is arranged. 
The keyword is used to determine how the request is processed. For example, the keyword 
"Profile A" can indicate that the request has a different format than the keyword "Profile B w and 
therefore should be processed differently. 

The Examiner states that Latif discloses "identifying a keyword in the first request, 
wherein the keyword indicates the format of information in the first request (abstract, col. 5, 
lines 57-67, col. 6, lines 1-14, lines 44-47 and col. 11, 41-52)." In the present invention, as 
recited in Claim 30, Applicant notes that the abstract; col. 5, lines 57-67; col. 6, lines 1-14, lines 
44-47; and col. 1 1 , lines 41-52 do not teach or suggest a keyword that indicates the format of 
information in a request. Col. 11, lines 41-52 reads: 

When a Fiber Channel device sends data frames to a device not 
located in its Fiber Channel address domain, switch 235 converts 
the packet into an SolP compatible packet. The conversion 
encapsulates the FCP data frame in IP data frame as described 
above. Referring back to FIG. 6a, in one embodiment, the IP 
addresses and the SolP socket numbers are derived by using 
the Fiber Channel source address (SJD) and destination 
address (D_ID) as "keys" into the IP/Fiber address conversion 
table on the name server. The Fiber Channel address fields are 
replaced by the SolP socket numbers when translating a Fiber 
Channel Data frame to a SolP data frame. 

The SJD and D_ID are fiber channel addresses commonly included in fiber channel 
frames. They are used to identify the source and destination for a particular frame. The switch 
of Latif extracts a source address and destination address from a fiber channel frame and 
determines corresponding SolP socket numbers from a lookup table (i.e., from the IP/Fiber 
Channel address conversion table on the name server). There is no teaching or suggestion the 
SJD and DJD indicate the format of other information in a request, nor is there any teaching or 
suggestion that the parses the request based on the SJD or DJD. Consequently, there is no 
teaching of a keyword that "indicates the format of the information in the first request" or that 
the request should be parsed "based on the keyword" as recited in Claim 30. Moreover, there 
is no teaching or suggestion in the portions of Latif cited by the Examiner of a device is 
configured to "generate a first request containing a keyword indicating an arrangement of 
information in the first request" or a switch is configured to "parse the first request based on the 
keyword," as recited in Claim 34. Accordingly, withdrawal of the rejection of Claims 30 and 34 



is requested. 
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Rejections under 35 U.S.C. S 103 

Claims 3, 5 and 14 stand rejected as obvious over U.S. Patent No. 6,400,730 ("Latif ) in 
view of U.S. Patent No. 6,256,739 ("Skopp"). 

Applicant notes that in order to establish a prima facie case of obviousness, the 
Examiner must show: that the prior art references teach or suggest all of the claim limitations; 
that there is some suggestion or motivation in the references (or within the knowledge of one of 
ordinary skill in the art) to modify or combine the references; and that there is a reasonable 
expectation of success. M.P.E.P. 2142, 2143; In re Vaeck , 947 F.2d 488, 20 U.S.P.Q.2d 1438 
(Fed. Cir. 1991). The Examiner must explain with reasonable specificity at least one rejection - 
otherwise, the Examiner has failed procedurally to establish a prima facie case of obviousness. 
M.P.E.P. 2142; Ex parte Blanc , 13 U.S.P.Q.2d 1383 (Bd. Pat Application. & Inter. 1989). When 
the motivation to combine the teachings of the references is not immediately apparent, it is the 
duty of the Examiner to explain why the combination of the teachings is proper. Ex parte 
Skinner 2 U.S.P.Q.2d 1788, 1790 (Bd. Pat. App. & Inter. 1986). 

Claim 3 recites "an HTTP server coupled to an HTTP client, wherein the HTTP server is 
configured to receive the requests formatted according to the first protocol from the first device 
and wherein the HTTP client is configured to forward corresponding requests formatted 
according to a fiber channel protocol to the second device on the storage area network." 
According to present invention, as recited in Claim 3, requests received by the HTTP server 
from a first device according to a first protocol can be sent to a second device according to a 
fiber channel protocol. The Examiner admits that the recitations of Claim 3 are not taught by 
Latif, but states that Skopp discloses a method and apparatus to determine user identity and 
limit access to a communication network including: "wherein an HTTP server coupled to an 
HTTP client, wherein the HTTP server is configured to receive the requests formatted according 
to the first protocol from the first device and wherein the HTTP client is configured to forward 
corresponding requests formatted according to a fiber channel protocol to the second device on 
the storage area network (abstract, col. 3, lines 52-67 and col. 6, lines 50-54). 

The abstract of Skopp reads: 

A method and apparatus to determine user 
identity and limit access to a communication 
network. A first message is received from a 
client computer in accordance with a first 
protocol. A first network address is determined 
from the first message. A second message 
containing an information request is also 
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received from the client in accordance with a 
second protocol, an a second network address is 
determined from the second message. The 
requesting user identity is then determined 
based on the first network address, the user 
identity information and the second network 
address. Based on the requesting user identity it 
can be decided whether to grant an information 
request. If access in granted, the requested 
information is retrieved using the 
communications network. 

Col. 3, lines 52-57 essentially repeat the abstract. The first request and second request 
of the abstract are both sent from the client computer. There is no teaching or suggestion in 
the abstract or col. 3, lines 52-57 that either request should be reformatted into a different 
protocol (e.g., fiber channel, for example). 

Col. 6, lines 50-54 reads: 



Thus, according to one embodiment of the present invention, an 
out of band protocol (PCP) is used to exchange information 
between the client access control application 210 and PCPD 330, 
which operates in parallel with the access control proxy 310. 

Applicant notes that the client access control application 210 referred to in this section of 
Skopp resides on the same client machine as the browser initiating the information request. 
See, Figure 1 B. The PCPD receives information from the access control application to 
authenticate a user having a particular IP address. If the user is authenticated, the access 
control proxy can use the IP address with the authenticated user to associate that user with 
future Web page requests having the same IP address. See, col. 6, lines 55-64. The PCP is 
used to communicate, for example, user name and IP address information, between the client 
computer and the PCPD. If a user is authenticated, then the control access proxy can allow 
web page requests from that IP address. Thus, the access control system of Skopp receives 
communications in two different protocols in parallel from the same client (i.e., receives PCP 
communications and web page requests). There is no teaching or suggestion in the portions of 
Skopp cited by the Examiner, however, that web page requests received by the access control 
device should be formatted in a second protocol before being sent to a second device. Thus, 
there is no teaching or suggestion that that an HTTP client should forward requests 
corresponding to those received by an HTTP server from a first device according to a first 
protocol to a second device according to another protocol (e.g., fiber channel). As Latif does 
not teach the recitations of Claim 3 and Skopp neither teaches nor suggests that "the HTTP 
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server is configured to receive the requests formatted according to the first protocol from the 
first device and wherein the HTTP client is configured to forward corresponding requests 
formatted according to a fiber channel protocol to the second device," Applicant respectfully 
requests allowance of Claim 3. 



New Claims 

Claim 39 recites that "the switch is configured to reformat the HTTP request to generate 
a second request according to a fiber channel protocol." Applicant submits that there is no 
teaching or motivation in Latif to reformat an HTTP request as a second request according to 
the fiber channel protocol as Latif deals with repackaging SCSI commands. Additionally, there 
is no teaching or motivation in Skopp to reformat an HTTP request as a fiber channel request 
as Skopp does not teach or suggest reformatting web requests in a different protocol. Skopp, 
instead, teaches sending a web request to an access control device and a separate PCP 
request. Based on user information in the PCP request, the access control device can 
determine whether to allow the web request. There is, however, no suggestion that the web 
request should be reformatted according to a fiber channel protocol. Therefore, Applicant 
respectfully requests allowance of Claims 39-41. 

Conclusion 

Applicant has now made an earnest attempt to place this case in condition for 
allowance. Other than as explicitly set forth above, this reply does not include an acquiescence 
to statements, assertions, assumptions, conclusions, or any combination thereof in the Office 
Action. For the foregoing reasons and for other reasons clearly apparent, Applicant respectfully 
requests full allowance of Claims 1-41. The Examiner is invited to telephone the undersigned 
at the number listed below for prompt action in the event any issues remain. 
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The Director of the U.S. Patent and Trademark Office is hereby authorized to charge 
any fees or credit any overpayments to Deposit Account No. 50-3183 of Sprinkle IP Law 
Group. 



Date: July 22, 2004 

P.O. Box 684767 
Austin, Texas 78768-4767 
Ph: 512.637.9220 
Fax: 512.371.9088 



Respectfully submitted, 

Sprinkle IP law Group 
Attorneys for Applicant 
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